Amazon WorkSpaces Poolsを試してみた

しばたです。

前の記事で紹介したAmazon WorkSpaces Poolsですが、本記事では実際に構築する手順を解説します。

https://dev.classmethod.jp/articles/amazon-workspaces-supports-workspaces-pools/

検証環境

今回構築する環境は下図となります。

私の検証用AWSアカウントの東京リージョンにVPCと各種リソースを作成します。
Microsoft Entra IDのテナントとVPC等のネットワークリソースは構築済みの状態をスタート地点とします。

作ってみた

それでは早速作成していきます。

Amazon WorkSpaces PoolsではSAML 2.0で連携できるIdPの利用が必須であるため、まずはIdP周りの設定から始める必要があります。
こちらは手順の都合AWSとEntra IDを行き来する必要があり、かなり間違いやすいのでご注意ください。

0. 前提条件 : Microsoft Entra ID

今回IdPにMicrosoft Entra IDを使います。
検証用にFree版のテナントを一つ用意し、example.shibata.techのカスタムドメイン名を割り当てています。

1. [AWS] Amazon WorkSpacesプールディレクトリ の仮作成

最初にAWS上でAmazon WorkSpaces Pools用のプールディレクトリを作成します。

プールディレクトリの設定を完全に終わらすにはEntra ID関連の設定が事前に必要なのですが、その設定のためにはプールディレクトリのIDが必要であり、まずは最初にEntra ID関連以外の設定を行う形で仮作成します。

AWSのマネジメントコンソールから Amazon WorkSpaces → ディレクトリ → プールディレクトリ へ移動し「WorkSpacesプールディレクトリの作成」を行います。

プールディレクトリの作成画面に遷移しますが、最初は「ユーザーアクセスURL」に適当なダミー値を設定^[1]し、「リレー状態パラメーター名」は未入力にします。
(Entra IDの設定後にこれらの値を更新します)

その他の設定に関しては「ディレクトリ名」や「ネットワーク」関連の設定を環境に応じて行います。
今回は以下の設定にしています。

• ディレクトリ名 : example.shibata.tech
• VPCとサブネット : WorkSpacpe環境を配置したいサブネットを指定
  • これは個人WorkSpacesと同様
• セキュリティグループ : WorkSpaceにアタッチするセキュリティグループを事前作成のうえ指定
  • 通常であれば「インバウンド通信全ブロック」「アウトバウンド通信全許可」で問題ない

今回「アクティブディレクトリ設定」は全て未設定のままとします。
(これはEntra IDとActive Directoryを同期している場合に使います)

「ストリーミングプロパティ」は環境に応じた内容にします。
今回は「ホームフォルダを有効化」以外は全てデフォルトのままにしています。

その他の設定もデフォルトのままです。
設定内容に間違いがないのを確認して「WorkSpacesプールディレクトリの作成」ボタンをクリックします。

ユーザーアクセスURLにダミー値を入れているのでエラーメッセージが表示されてしまいますが、これは意図したものなので問題ありません。

Pools ディレクトリを作成できませんでした。この問題が続く場合は、AWS Support Center にお問い合わせください。
ディレクトリ wsd-hbp37pfnq は正常に作成されましたが、値の設定中にエラーが発生しました。ディレクトリを調べて、正しくない設定をすべて編集してください。残りの手順は ModifySAMLProperties,ModifyTargetDomainAndOrganizationalUnits,ModifyStreamingProperties,ModifyIamInstanceRole,ModifyClientProperties です

現時点ではプールディレクトリが作成され、ディレクトリIDが取得できればOKです。

2. [Entra ID] Entra IDエンタープライズアプリケーションの作成

次にWorkSpaces Poolsの認証用にEntra IDのエンタープライズアプリケーションを用意します。
Entra IDのコンソールから「エンタープライズアプリケーション」を作成します。

現状ギャラリーにはWorkSpaces Pools用のアプリケーションは無い様なので「＋独自アプリケーションの作成」を選びます。

アプリケーション名は任意の名前でOKです。
今回は「AmazonWOrkSpacesPoolsApp」という名前にしています。

作成されたアプリケーションから「2. シングルサインオンの設定」を選び、

シングルサインオン方式の選択で「SAML」を選びます。

SAML設定画面に遷移するのでhttps://signin.aws.amazon.com/static/saml-metadata.xmlからダウンロードしたメタデータファイルをアップロードしてやります。

• https://signin.aws.amazon.com/static/saml-metadata.xml

アップロードした結果はそのまま「保存」します。

続けてSAML証明書の「フェデレーションメタデータXML」をダウンロードします。

3. [AWS] IAM IDプロバイダの作成

次はAWSのマネジメントコンソールからIDプロバイダの登録を行います。
マネジメントコンソールから、IAM → アクセス管理 → IDプロバイダ を選び「プロバイダを追加」します。

プロバイダのタイプを「SAML」にし、プロバイダ名を任意の名称にします。(今回はEntraID-for-AmazonWorkSpacesPoolsにしています)
そして「メタデータドキュメント」欄に前節でダウンロードした「フェデレーションメタデータXML」をアップロードします。

この状態で「プロバイダを追加」ボタンをクリックして新しいプロバイダを作成してやります。

4. [AWS] IAMロールの作成

続けてフェデレーション用IAMロールを作成します。
AWSのマネジメントコンソールからIAMロールを選択し「ロールを作成」します。

IAMロールの作成ウィザードが開始されるので、次の設定をしたうえで「次へ」進みます。

• 信頼されたエンティティタイプ : SAML 2.0 フェデレーション
• SAML 2.0ベースのプロバイダー : 前ステップで作成したIAM IDプロバイダ (EntraID-for-AmazonWorkSpacesPools)
• 許可されるアクセス : 「プログラムによるアクセスのみを許可する」
• 属性と値 : 「SAML:sub_type = persistent」

許可ポリシーの設定は未指定のまま「次へ」をクリックします。

ロール名を任意の名前にして一度作成します。
今回は「EntraID-for-AmazonWorkSpacesPools-Role」

一度作成した後でロールを編集しなおして、以下の様に設定を変更します。
(ウィザードで細かく設定できない部分のため一度作成してからの変更が必要)

• 1. 信頼されたエンティティのJSON定義の「"Action"」に「"sts:TagSession"」を追加する

上図の様に"sts:AssumeRoleWithSAML"と"sts:TagSession"が許可されていればOKです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::xxxxxxxxxxxx:saml-provider/EntraID-for-AmazonWorkSpacesPools"
            },
            "Action": [
                "sts:AssumeRoleWithSAML",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "SAML:sub_type": "persistent"
                }
            }
        }
    ]
}

• 2. 許可ポリシーに以下インラインポリシーを追加する
  • 名前は任意
  • ポリシーのJSONは下記参照

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "workspaces:Stream",
            "Resource": "<Amazon WorkSpacesプールディレクトリのARN>",
            "Condition": {
                "StringEquals": {"workspaces:userId": "${saml:sub}"}
            }
        }
    ]
}

これでIAMロールの設定は完了です。

5. [Entra ID] エンタープライズアプリケーションのクレーム設定

今度はEntra IDに戻ってエンタープライズアプリケーションのクレーム設定を行います。

エンタープライズアプリケーションのSAML設定から「属性とクレーム」を編集します。

既存の設定に対し下表の内容で更新とクレームの追加を行います。

• ※1 : 環境によってはUPN以外にするケースもある模様 (詳細は下記ドキュメント参照)
• ※2 : スペースを含まない値であれば良く、メールアドレスでも構わない模様 (詳細は下記ドキュメント参照)

具体的な設定内容については以下のドキュメントを参照してください。

• Step 7: Create assertions for the SAML authentication response

最低限

• https://aws.amazon.com/SAML/Attributes/Role
• https://aws.amazon.com/SAML/Attributes/RoleSessionName
• https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email

の3クレーム増やす必要があり、Role属性に関しては「"<AWS IAM IDプロバイダのARN>,<AWS IAMロールのARN>"」の形式で値を埋めてやります。

# 設定例
arn:aws:iam::xxxxxxxxxxxx:role/EntraID-for-AmazonWorkSpacesPools-Role,arn:aws:iam::xxxxxxxxxxxx:saml-provider/EntraID-for-AmazonWorkSpacesPools

6. [Entra ID] エンタープライズアプリケーションのリレー状態設定

つづけてエンタープライズアプリケーションの「リレー状態」を設定します。

エンタープライズアプリケーションのSAML設定から「基本的なSAML構成」を編集します。

編集画面下部にある「リレー状態」に以下の値を設定して保存します。

# 設定形式
https://<リージョン毎のリレー状態エンドポイント>/sso-idp?registrationCode=<プールディレクトリの登録コード>

# 設定例
https://workspaces.euc-sso.ap-northeast-1.aws.amazon.com/sso-idp?registrationCode=wsnrt+XXXXXX

エンドポイントの一覧は以下のドキュメントでご確認ください。

• Step 8: Configure the relay state of your federation

7. [Entra ID] エンタープライズアプリケーション利用ユーザーの登録

あとはエンタープライズアプリケーションの利用ユーザーの設定を行ってください。

こちらの手順は割愛しますが、今回は織田信長ユーザーがこのアプリケーションを使う設定にしています。

これでEntra ID側の設定は完了です。

8. [AWS] Amazon WorkSpacesプールディレクトリ の本登録

最後にダミー値にしていたWorkSpacesプールディレクトリのSAML 2.0設定の本登録を行います。

AWSのマネジメントコンソールからWorkSpacesプールディレクトリの「認証」を選び「SAML 2.0 アイデンティティプロバイダーの編集」をクリックします。

「SAML 2.0認証の有効化」にチェックを付け、次の内容を登録します。

具体的な設定値については以下のドキュメントを参照してください。

• Step 9: Enable integration with SAML 2.0 on your WorkSpace Pool directory

登録が完了し、ステータスが「有効」になっていればOKです。

これでディレクトリ設定は全て完了となります。

動作確認

これでやっとAmazon WorkSpaces Poolsの環境構築ができます。

AWSマネジメントコンソールのWorkSpaces欄から「プール」タブを選び「WorkSpaceの作成」をクリックします。

WorkSpace作成ウィザードが開始されるので、今回は「自分のユースケースに必要なオプションを把握している」を選び「次へ」進みます。

基本情報の入力欄ではタイプを「プール」にし、名前などは適当な値にしておきます。
今回バンドルはStandardタイプのWindows 10 (Windows Server 2022)にしています。

「設定」欄はプールされるWorkSpaceインスタンスのスケーリングに関する設定となり、おおむねAppStream 2.0フリートの設定と同じです。
今回は動作確認用なのでデフォルト値をそのまま設定しています。

次に使用ディレクトリを選ぶので先ほど作成したディレクトリを選択し「WorkSpaceプールの作成」ボタンをクリックします。

これでプールが作成されました。
初期状態では「停止」していますので、「起動」してやると実際に接続可能になります。

起動までAppStream 2.0同様10分程度^[2]かかるので気長に待ちます。
最終的に状態が「起動中」になればOKです。

この状態でWorkSpaces Clientを起動しEntra IDのユーザーでログインしてやればWorkSpace環境を利用できます。

ブラウザが開きEntra IDのログイン処理が始まるので適切なユーザー情報を入力すると

WorkSpaces Clientへ戻り、

最終的にWorkSpace環境が利用できます。

OSユーザーがPhotonUserだったりするのは前の記事で紹介した通りです。

その他補足など

最後にAmazon WorkSpaces Poolsを試して気が付いた点をいくつか紹介します。

自動作成されるS3バケット

Amazon WorkSpaces Pools環境を構築するとwspool-で始まるS3バケットが自動で作成されます。

それぞれ

• wspool-app-settings-<リージョン名>-<アカウントID>-ランダムID → ユーザープロファイル用VHDファイル等の置き場
• wspool-home-folder<リージョン名>-<アカウントID>-ランダムID → ホームフォルダのデータ保存用
• wspool-logs-<リージョン名>-<アカウントID>-ランダムID → セッションスクリプト利用時のログファイル置き場

となっています。

設定保存とホームフォルダの扱い

最初に「S3にVHDファイルを保存する」点に気が付いたせいでVHDファイル全体が永続保存されるのかと誤解していたのですが間違っていました。
VHDファイルはあくまでも「アプリケーション設定の保存用」であり、VHD内部の以下のフォルダは除外されて永続化されます。

• Contacts
• Desktop
• Documents
• Downloads
• Links
• Pictures
• Saved Games
• Searches
• Videos

WorkSpaces Pools環境を試し始めた当初、デスクトップにファイルを保存したものの永続化されない事象が発生しかなりハマっていたのですがこの仕様によるものでした。

• 参考 : How Application Settings Persistence Works

代わりに利用者のデータは「ホームフォルダ」に保存します。
ざっくりAppStream 2.0のホームフォルダと同様と考えてもらえばOKです。

このホームフォルダは

• 通常利用時 : C:\Users\PhotonUser\My Files\Home Folder
  • 実体としては C:\ProgramData\UserDataFolders\<ユーザーのSID>\My Files に存在する
• Active Directory連携時 : C:\Users\%username%\My Files\Home Folder

にあり、ぱっと見では分かりにくい場所にあります。

このフォルダはS3バケットのユーザー毎のPrefixと同期されており、だいたい数分程度の間隔で同期されている様です。

アプリケーション設定のVHDとは異なりS3バケットに直接ファイルが保存される形となっています。
このためあまり激しいアクセスは想定されておらず、激しいI/Oがある場合はFSx for Windows等のファイルサーバーの利用が推奨されています。

• 参考 : Enable and Administer Persistent Storage for WorkSpaces Pools

ちなみにWorkSpaces Pools環境を削除してもS3バケット内のデータは残り続けます。
前述の参考資料によれば

As mentioned earlier, disabling home folders for directories does not delete any user content stored in the Amazon S3 bucket. To permanently delete user content, an administrator with adequate access must do so from the Amazon S3 console.

とのことです。

DesiredUserSessions

スケーリング設定に関してAppStream 2.0のDesired capacityに相当する値としてDesiredUserSessionsが存在します。
ただ、この値はマネジメントコンソールのUI上は完全に隠蔽されており直接値を変更することはできない様です。

AWS CLIからはその内容が確認できるので参考にすると良いでしょう。

# AWS CLIからだと DesiredUserSessions を確認できる
$ aws workspaces describe-workspaces-pools --pool-ids wspool-xxxxxxxxx
{
    "WorkspacesPools": [
        {
            "PoolId": "wspool-xxxxxxxxx",
            "PoolArn": "arn:aws:workspaces:ap-northeast-1:xxxxxxxxxxxx:workspacespool/wspool-xxxxxxxxx",
            "CapacityStatus": {
                "AvailableUserSessions": 0,
                "DesiredUserSessions": 2,
                "ActualUserSessions": 1,
                "ActiveUserSessions": 1
            },
            "PoolName": "MyPool1",
            "Description": "My first WorkSpaces Pools",
            "State": "RUNNING",
            // ・・・後略・・・
        }
    ]
}

セッション(=WorkSpace)の終了タイミングについて

AppStream 2.0では公開アプリケーション(または公開デスクトップ)の利用が終了すると直ちにFleetインスタンスが破棄されましたが、WorkSpaces Poolsでは少し異なる様です。

WorkSpaces Clientを終了しても直ちにセッションが終了しWorkSpaceインスタンスが破棄されることは無く「NOT_CONNECTED」なステータスで残り続ける挙動をしました。
WorkSpaces Poolsの場合はCLI(およびAPI)で明示的に終了しない限り「切断タイムアウト」で指定した時刻まで(今回の場合だと15分間)セッションが残り続ける形になる様です。

# WorkSpaces Clientを終了しても ConnectionState = NOT_CONNECTED な状態でセッションは残り続ける
$ aws workspaces describe-workspaces-pool-sessions --pool-id wspool-xxxxxxxxx
{
    "Sessions": [
        {
            "AuthenticationType": "SAML",
            "ConnectionState": "NOT_CONNECTED",
            "SessionId": "c6309573-6c64-4645-918c-d4ab35c10ed2",
            "InstanceId": "i-xxxxxxxxxxxxxxxxx",
            "PoolId": "wspool-4h55tcgzv",
            "ExpirationTime": "2024-07-11T15:45:50.124000+09:00",
            "NetworkAccessConfiguration": {
                "EniPrivateIpAddress": "10.0.21.74",
                "EniId": "eni-xxxxxxxxxxxxxxxxx"
            },
            "StartTime": "2024-07-10T23:45:50.124000+09:00",
            "UserId": "xxxxxxxxxx@example.shibata.tech"
        }
    ]
}

# 15分待つとセッションが消えた
$ aws workspaces describe-workspaces-pool-sessions --pool-id wspool-xxxxxxxxx
{
    "Sessions": []
}

明示的にセッションを終了するにはaws workspaces terminate-workspaces-pool-sessionコマンドを使います。

# セッションIDを指定して終了
aws workspaces terminate-workspaces-pool-session --session-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

最後に

以上となります。

SAML 2.0連携にかなりの手間がかかり疲れました...
一旦SAML 2.0連携ができてしまえば後はおおむねAppStream 2.0と同じなのでそこまで苦労することは無いと思います。

参考ドキュメント

Amazon WorkSpaces Pools環境を作りにあたり以下の公式ドキュメントが役に立つので参考にしてください。
(というかこれらを精読しないとハマりまくります...)

• Configure SAML 2.0 and create a WorkSpaces Pools directory
  • まずはこのドキュメントを基本にしてください
• Integrate SAML 2.0 with WorkSpaces Personal
  • 従来のWorkSpaces(Personal)のSAML 2.0連携の手順も役に立ちます
  • ただし、WorkSpaces Poolsの手順と微妙に異なるので間違わない様に注意してください
• Amazon WorkSpaces SAML Authentication Implementation Guide (pdf)
  • 各IdP側の設定を確認するのに役立ちます